Should we use CertHub's structure or build our own?
If you are setting up CertHub for a medical device organization, use CertHub's structure as your starting point. In practice, that means using Guided Setup and the libraries CertHub provides, then adapting them where your device really needs it.
Do not start from a blank product and rebuild your whole structure from scratch unless there is a very specific gap that the provided setup cannot cover.
Short answer
Choose CertHub's structure if you want:
- a setup that already reflects MDR or IVDR expectations
- a cleaner path into risk management, requirements, verification, and validation
- less rework during onboarding
- faster support from the CertHub team
Choose a more custom setup only when you need to add product-specific content on top of the provided structure, not instead of it.
Why this is the better default
Most QM and RA teams are not trying to invent a new structure for technical documentation. They are trying to get to a reliable, auditable setup quickly.
That is exactly what CertHub's structure is for:
- It already comes with a regulatory-oriented setup for technical documentation, risk management, and design control.
- Guided Setup adjusts the package based on your regulation and product class.
- The provided structure is aligned with the templates, processes, and traceability patterns already described across the CertHub docs.
- If your team uses the common CertHub structure, support can answer questions much faster because you are speaking the same language.
What goes wrong when teams rebuild everything themselves
On paper, starting from scratch can feel attractive because it resembles your old folder structure, Excel files, or Word templates.
In practice, it often creates four problems:
1. Your technical file stays harder to control
If you simply recreate your old document logic inside CertHub, the real source of truth often remains outside the system. That weakens traceability and makes reviews harder.
2. Important relationships become harder to maintain
CertHub is strongest when requirements, risks, controls, verification, and validation live in a structure that already expects those links. If you redesign that structure too heavily, you create more manual work and a higher chance of gaps.
3. Prebuilt outputs stop fitting cleanly
Areas such as EUDAMED-related output, templates, and guided product structures work best when the underlying setup still follows the CertHub model.
4. Every support question becomes custom
If your setup is completely private, every onboarding or support conversation starts with explaining your model first. That costs time on both sides.
Choose this when
Use CertHub's structure when:
- you are implementing CertHub for the first time
- you want a strong starting point for MDR or IVDR work
- you need an auditable setup without designing every category yourself
- you want CertHub support to guide you efficiently
- your current structure mainly comes from legacy folders, spreadsheets, or document habits
Do not do this when
Do not rebuild everything from scratch just because:
- your existing folder names feel familiar
- your previous technical documentation lived in Word and Excel
- different departments currently use different labels for similar information
- you assume a custom structure will be "cleaner" before you have used the standard one
What you should still customize
Using CertHub's structure does not mean your setup must stay generic.
You should absolutely adapt the setup where your device needs it. For example:
- a sterilizer may need more depth around sterility and reprocessing
- a SaMD product may need more depth around software architecture or SOUP
- your team may need extra fields or lists for internal review or operational clarity
That kind of extension is healthy. The key is to extend the structure, not replace its core logic.
A practical example
Imagine two Class IIa manufacturers starting at the same time.
Team A uses Guided Setup, keeps the provided structure, and adds a few device-specific details on top.
Team B starts from a blank product and rebuilds the structure around its old Word dossier.
Six months later, Team A has a clearer path from requirement to verification and from risk to control measure. Team B still has information in CertHub, but its old document logic is still driving too many decisions, so traceability is weaker and support discussions take longer.
Recommendation
If you are unsure, treat CertHub's structure as the safe default.
Start with Guided Setup. Use the provided libraries. Add only what your device truly needs. This gives QM and RA a stronger basis for traceability, review readiness, and long-term maintainability.